<syntaxSimilarToASubsetOfRuby>

Continuing from createExampleNode.13.xml

<summaryOfProblems>
	I am finding it hard to merge trees of Func that represent sizes with trees of Func that control current index in iteration, and by getting arrays from child nodes from a small constant depth, I lose the ability to calculate the iteration size before the iteration starts.

	All descendant Funcs of the one you call must do their whole iteration, or the other option is to tell it to run the next iteration part without knowing how many more there are.

	Even if we could know the iteration size before iterating, the Funcs that are used the most will be optimized as Java classes and lose that ability, or partially optimized and keep some of that ability.
</summaryOfProblems>

<goal>
	Need to stop thinking about data structures for now and define the behavior I want, then define the data structures.
</goal>

aray = a real aray in memory.
	Examples: int[], Object[], double[], Func[].
	Contains the same type of things. Specific indexs can not be defined to contain different types of things.
	Maybe: aray extends indirectAray, and indirectAray extends virtualList.

indirectAray = a real aray or an aray found recursively through child nodes.
	Maybe: aray extends indirectAray, and indirectAray extends virtualList.
	Example: virtualFloListAtIndex19 could be defined as the floListAtIndex10 aray of the current child in childListAtIndex5,
	and when iterating over childListAtIndex5, virtualFloListAtIndex19 becomes the floListAtIndex10 of a different child node each time.
	All arays can be defined as virtualAray if the root node is defined as a child of the funcState,
	and that would be faster for some calculations because arays that are not used would not have to be put in the funcState.

virtualList = like an aray but having no data lets it be much bigger. Its used for iterating over combinations of arrays and doing trees of calculations and reads/writes.
	Maybe: aray extends indirectAray, and indirectAray extends virtualList.
	(Maybe this should be combined with Func. Maybe virtualAray should be combined with aray. Many combinations are possible to be good design.)

node = constant-size obAray containing different types of arays whose sizes depend on eachother and are defined using 1 of these Func per aray:
	range(between 2 int constants)
	size*(x y)
	size^(x y)
	Node does not extend aray because aray "Contains the same type of things. Specific indexs can not be defined to contain different types of things."

virtualNode = A virtual interpretation of a + function, and real aray are only created in funcState, and funcState may contain other funcState. funcState are defined as virtual so all data in the whole software would be virtual until its copied to a file. Its similar to size* and size^ because it combines 2 things which can be different types, but is different because only 1 of those 2 things is used at a time, which would make iterating hard to define. It would allow optimizations like combining 4 size-1 floArays into 1 size-4 floAray.

funcState = All information and/or data structures and/or Funcs that a Func uses to store things in while it reads/writes things in a node. A funcState is created already containing some of these things in the node, then is the parameter of a Func call which does something to that node and/or its descendants. FuncStates may be recursive. Each funcState represents at most a small constant quantity of specific recursions. An example of constant depth specific recursion is add child of child of child's seventh flo to child of childs third flo.
	There can be many polyIndex in a funcState.

func = an object with a function that takes 1 funcState parameter (or the parts of a funcState each as a different parameter) and returns in a predictable maximum time. There may be multiple standard ways to call every Func, including:
	* Do the smallest amount of things possible.
	* Do constant-depth-recursion in 1 funcState and return any funcStates that need to be called, and allow continuing execution after you execute those funcStates separately.
	* Do the whole unpredictable-max-time variable-depth-recursion.
	Each Func has 0 or more child Funcs and that never changes.
	OPTIMIZABLE: Some trees of Func can be ***optimized as a Java class*** that does the same thing as the tree but is 1 Func that has as many parameters as the inputof the root plus the outputs of the leafs in the tree had. An optimized version of a Func can use the same types of funcState but could also create a different optimized version that uses a smaller funcState that excludes the indexs used for the middle of the calculation (Its best to remove those because they are ignored and other code may, but shouldnt, expect them to be used).
	Each func modifies the int indexs and/or aray in a polyIndex, and/or modifies the data in arays in a node.
	Example func: flo+=flo(floArayA floArayB)
	Example func: factor^(bPowerCThenMultC bPowerC c setIndexOfBHere) or maybe it should be remove^(bPowerC c setIndexOfBHere) or remove^*(bPowerCThenMultC setIndexOfBHere)

How to define constraints on the content of some arrays?
	Example: the 2 intAray in a heapQueue must always point at eachother symmetricly.
	Example: the floAray in a heapQueue must run a heapQueueFunc on floAray and 2 intArays in the heapQueue, to reorder the flo in the 2 intAray if the flo changed enough. After that func is done, the root index (is it 0 or 1?) of the first intAray must contain the int index of the max flo in floAray.

========================================

<thisIsTooMuchAboutOpimizationAndNotEnoughAboutDefiningBehavior>
	polyIndex = Data is: 1 or more int indexs in the same aray, and the aray. This avoids most of the need to have multiple variables pointing at the same aray.
		Maybe: polyIndex extends virtualList of int.
		PolyIndex may complicate the design too much and be replaced by 1 int index per 1 pointer to aray, and allow duplicate pointers to the same aray while having different or equal int indexs for it.
</thisIsTooMuchAboutOpimizationAndNotEnoughAboutDefiningBehavior>

polyIndex includes multiple int index and 1 aray. Should it also have multiple aray from the same node that are equal size?
Or should there be 2 different types of things: monoArayPolyIndex and polyArayMonoIndex?

For now, ignore efficiency and how to implement this and exactly define the behavior we want.

simpleArayGroup = the information in, but not the data structure of, these 3 arays:
	* int curIndex[any size], contains independent ints between 0 and arayAray[0].length-1.
	* int whichAray[curIndex.length], contains independent ints between 0 and arayAray.length-1.
	* Object arayAray[any size], contains any arays that are always the same size and can be different types.
This may be useful for optimizing nodes where some arays must be the same size always, but the behavior should be defined before starting on optimizations like these.

virtualNode (abbrev: vn) = The information but not data structures of...
	* a view of a single variable-size aray, and a current int index, or
	* virtualNodeA + virtualNodeB (should it allow any constant quantity of virtualNodes instead of just 2?), and a current int index from 0 to sum of their sizes - 1.
VirtualNode can give many subVirtualNodes as efficiently as String can give many substrings.

A bayesian algorithm would use:
bayesNode = vnFalseTrue + vnChilds + vnWeights + vnWeightSums
vnFalseTrue = between 2 and 2
vnChilds = between 1 and 7
vnWeights = vnFalseTrue ^ vnChilds
vnWeightSums = vnFalseTrue * vnChilds

bayesNode = vnFalseTrue + vnChilds + (vnFalseTrue^vnChilds) + (vnFalseTrue*vnChilds)

Should aray of x size y be defined as x^y?
Example: int = bit^32
Example: int[3] = (bit^32)^3
Example: Object[]{ int[3], flo[4] } = (bit^32)^3 + (definition of flo)^4

Maybe there should be no flo, and use arays of bits (often optimized as java ints) instead, converting them to flo only in the middle of calculations that need flos like java.lang.Math.sin(flo).

Define iterating over all possible int values as bit^32.
Define each specific int value as bit*32.
Define int[3] as (bit*32)^3. This definition is vague. What size loop? How many data (1 or 3) in each iteration?

Define ^ as loop.
Define * as specific value.
What should bit be defined as? Should bit be one of 0 or 1? Should bit be one of * or ^?
Should [+, *, ^] be viewed as [-1, 0, 1]?
Should [+, *, ^] be viewed as [0, 1, []]?
Or, similar to a base-negativetwo or base-negativethree or base-sqareRootOfNegativeFour positional number system,
should one of Audivolv's main data types be number whose base is defined as some combination of * and ^?
Maybe call it a base-specificValueXorLoop positional number system. I'm not sure about the Xor, but "specificValue" and "Loop" must have some logic word between them.

Simplify. Ignoring efficiency and data structures, list the main ideas here:
* literal(x) //1 time, not a loop. observe a qubit or combination of them, or observe the fact that they are qubits in some combination without observing their values.
* 0
* 1
* qubit //May be 0 or 1, until observed by a loop(x). http://en.wikipedia.org/wiki/Qubit
* loop(x) //observe all possible combinations of x, viewing each as literal
* cat(x y)

Examples:
cat(cat(1 0) 1) is 5
cat(cat(1 qubit) 1) is 2 possible things: 101 and 111.
loop(cat(cat(1 qubit) 1)) is both in sequence: 101 then 111.
literal(loop(cat(cat(1 qubit) 1))) is the literal description of "both in sequence: 101 then 111".

cnum(x y) = a complex number of this form: x + sqrt(-1)*y.
cnum(x y)^2 = (x + sqrt(-1)*y)*(x + sqrt(-1)*y) = x^2 - y^2 + sqrt(-1)*2*x*y

If cnum(b c)^2 + cnum(d e)^2 == 1, then:
b^2 - c^2 + sqrt(-1)*2*b*c + d^2 - e^2 + sqrt(-1)*2*d*e == 1
and simplified:
b^2 - c^2 + d^2 - e^2 == 1
and
b*c + d*e == 0

Are complex numbers and quantum equations useful in any way for defining loops, variables, and control-flow in Audivolv?

A normal bayesian-node with 5 child nodes (including itself) has 32 chances that sum to 1. Should each chance be a complex number? Should each chance be a recursively complex number defined as some tree of child bayesian-nodes (avoiding exponential cost by running each node only once)?

Every normal bayesian network is a quantum bayesian network where all complex numbers have 0 imaginary (sqrt(-1)) part.

An internet search for "quantum bayesian" finds lots of pages. Some are from the 1990s and claim that quantum bayesian networks would fun faster on a quantum computer than a normal computer.

Again...
list the main ideas here:
* literal(x) //1 time, not a loop. observe a qubit or combination of them, or observe the fact that they are qubits in some combination without observing their values.
* 0
* 1
* varBit //May be 0 or 1, until used by loop(x)
* loop(x) //observe all possible combinations of x, viewing each as literal
* cat(x y)

Examples:
cat(cat(1 0) 1) is 5
cat(cat(1 varBit) 1) is 2 possible things: 101 and 111.
loop(cat(cat(1 varBit) 1)) is both in sequence: 101 then 111.
literal(loop(cat(cat(1 varBit) 1))) is the literal description of "both in sequence: 101 then 111". This is confusing.

These things can not simply represent integers that are not powers of 2.
Instead, define these higher level main ideas:
* int = a specific nonnegative integer
* cat(x y z...) = aray containing x, y, z...
* *(x y) = multiply operator. Resulting size: x multiply y. For each thing in the resulting size: 1 variation of x and 1 variation of y.
* ^(x y) = power operator. Resulting size: x power y. For each thing in the resulting size: y quantity of variations of x.
Maybe cat should be renamed to +.
* +(x y) = concatenate operator. Resulting size: x plus y. For each thing in the resulting size: 1 variation of x or 1 variation of y, and maybe: 1 int index in the aray that contains x and y.
Example: b is size 5. c is size 10. d is size 12. e is size 3. +(b c d e) is size 30, and for each of those 30 things, there are 2 ints.
Those 30 things range 0 to 29.
Thing number 4 gives [0,4].
Thing number 5 gives [1,0].
Thing number 8 gives [1,3].
Thing number 29 gives [3,2] because e is array number 3 and b+c+d+2 is 29.
This is a good way to abstractly define concat.

Should ^(x y) be defined as giving an array size y for each of x^y quantity of things? Aray is +. If y is 5, then it gives 32 arrays like this: +(x x x x x) with 5 specific values of x. Maybe *(x y) is better because "each thing in the resulting size" is size 2 instead of size 5. +(x x x x x) is more correct if it is not iterated over. Just use the 5 specific values of x.

//b is 2. c is 3. d is 4. e is 5. f is 6.

int
+(b c) - Iteration size can not be simplified. Data size is +(x y) where x is size 2 and size of y depends on value of x. size of y is size of b or size of c.
//Approximations: iteration size eval(+(b c)) - data size is not cartesian. +(+(2 b) +(2 c)), +(2 or(b c)), +(+(1 b) +(1 c)), +(b c)
*(b c) - iteration size +(b b b)     - data size +(b c).
^(b c) - iteration size *(b b b)     - data size +(b b b).

//Theoretically, if this pattern continues, what is the next operator?
?(b c)  - iteration size ^(b b b)? - data size *(b b b)

^(^(b b) b) <= ^(b ^(b b))
Example: 5^5 = 3125
^(^(5 5) 5) = 298023223876953125
^(b ^(b b)) = 1.911012597945477520356404559704e+2184

^(^(2 2) 2) = 16
^(^(3 3) 3) = 19683
^(^(4 4) 4) = 4294967296

This theoretical operator creates numbers that are too big to be practical in AI algorithms.
The only operators needed for aray size and iterating are:
+ plus/concat
* multiply
^ power

Iteration size of x is always 1 integer, the same as eval(x).
Data of x is different in each eval(x) quantity of iterations and is always an aray.

b is 2. c is 3.

+(b c) - Data is +(2 b) or +(2 c), depending on the value of the thing that is size 2.
*(b c) - Data is +(b c).
^(b c) - Data is +(b b b). //Data of +(b b b) is +(b c) because c is 3.

^(c b) - Data is +(c c). //Data of +(c c) is +(c b) because b is 2.



Is +(b b b) an operator? It is the + of variations of the same type of thing.

+(b c)                                         --> +(2 b) or +(2 c)
*(b c)                              --> +(b c) --> +(2 b) or +(2 c)
varSize+(b b b)                     --> +(b c) --> +(2 b) or +(2 c)
^(b c)          --> varSize+(b b b) --> +(b c) --> +(2 b) or +(2 c)

Some of those transformations lose information and some dont.

Example: Given current values of b and c, and constant sizes of b and c,
[+(b c) --> +(2 b) or +(2 c)] loses 1 of the current values.
[+(b c) --> +(2 b) and +(2 c)] loses nothing, and the values of each 2 are redundant.

Example: Given current values of each b, and constant size of b and size of the varSize+ is the size of c,
[varSize+(b b b) --> +(b c)] keeps only the current value of 1 b, and the value of c which tells which b.

Need to specify more detail about size, current index, and array vs iterating over that array, and recursion.

Should varSize*(b b b) be added here?:
^(b c) --> varSize*(b b b) --> varSize+(b b b) --> +(b c) --> +(2 b) or +(2 c)


+(b c)                                                              --> +(2 b) or +(2 c)
*(b c)                                                   --> +(b c) --> +(2 b) or +(2 c)
varSize+(b b b)                                          --> +(b c) --> +(2 b) or +(2 c)
varSize*(b b b)                      --> varSize+(b b b) --> +(b c) --> +(2 b) or +(2 c)
^(b c)          <--> varSize*(b b b) --> varSize+(b b b) --> +(b c) --> +(2 b) or +(2 c)

Simplify:
+(2 b) or +(2 c)                                                                         --> 2
+(b c)                                                              --> +(2 b) or +(2 c) --> 2
*(b c)                                                   --> +(b c) --> +(2 b) or +(2 c) --> 2
varSize+(b b b)                                          --> +(b c) --> +(2 b) or +(2 c) --> 2
varSize*(b b b)                      --> varSize+(b b b) --> +(b c) --> +(2 b) or +(2 c) --> 2

null is 0.

Simplify:
null                                                                                               --> error
1                                                                                         --> null --> error
2                                                                                   --> 1 --> null --> error
+(b c)                                                                        --> 2 --> 1 --> null --> error
*(b c)                                                             --> +(b c) --> 2 --> 1 --> null --> error
varSize+(b b b)                                         --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
varSize*(b b b)                     --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
^(b c)          --> varSize*(b b b) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error

Reorder so more information is to the left of the arrows. Null is 0, and error can be ignored. Type of operator can be stored in a byte.
null                                                                                      --> error
1                                                                                --> null --> error
2                                                                          --> 1 --> null --> error
+(b c)                                                               --> 2 --> 1 --> null --> error
*(b c)                                                    --> +(b c) --> 2 --> 1 --> null --> error
varSize+(b b b)                                --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
^(b c)                     --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
varSize*(b b b) --> ^(b c) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error

0   null                                                                                      --> error
1   1                                                                                --> null --> error
2p  2                                                                          --> 1 --> null --> error
3p  +(b c)                                                               --> 2 --> 1 --> null --> error
4   *(b c)                                                    --> +(b c) --> 2 --> 1 --> null --> error
5p  varSize+(b b b)                                --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
6   ^(b c)                     --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error
7p  varSize*(b b b) --> ^(b c) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> null --> error

p means prime. Do the 4 prime things in those 8 things mean anything about prime numbers in general?

???
Not prime: 0, 1, *, ^
Prime:     2, +, varSize+, varSize*
???


varSize*(b b b) --> ^(b c) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> 0


[THIS IS IMPORTANT]
7p                          6          5p                          4          3p         2p     1     0
varSize*(3 3 3 3 3 3 3) --> ^(3 7) --> varSize+(3 3 3 3 3 3 3) --> *(3 7) --> +(3 7) --> 2  --> 1 --> 0

Every node is constant size + which contains different types of varSize+ and possibly varSize* and combinations of these 8 things.

Should varSize* and varSize+ have an extra parameter that is array size?
Example: varSize*(7 3 3 3 3 3 3 3) or it may be better written as varSize*(3 3 3 3 3 3 3)[7]
Example: varSize+(4 3 3 3 3) or it may be better written as  varSize+(3 3 3 3)[4]

varSize*(3 3 3 3 3 3 3)[?]
^(3 7)[2]
varSize+(3 3 3 3 3 3 3)[?]
*(3 7)[2]
+(3 7)[2]
2[1]
1[0] //should this be 1[1]? //You cant choose 1 of 1 things if you have 0 data to express that choice. You have to define what that 1 thing is somewhere. For that, we need more than 1 number: size and currentIndex.
0[error] //should this be 0[0]?



[END: THIS IS IMPORTANT]

varSize^ would be next, and varSize^^ may be the version that evaluates right to left to get an exponentially bigger result.
varSize^(3 3 3) means ^(^(3 3) 3), and varSize^^(3 3 3) means ^(3 ^(3 3))


Can any nonnegative int be defined in terms of these 8 things, starting with 0 and 1?

7                           6          5                           4          3          2      1     0
varSize*(3 3 3 3 3 3 3) --> ^(3 7) --> varSize+(3 3 3 3 3 3 3) --> *(3 7) --> +(3 7) --> 2  --> 1 --> 0

varSize* defines positional number systems with any positive base.
Lets choose base 2 in this example.
varSize*(2 2 2 2 2 2 2)

Start simpler...
0
1
2
3 = +(b c), Example: +(2 1)
4 = *(b c), Example:
5 = varSize+(1 1 1 1 1)
6 = ^(3 7)

Thats confusing. Lets add the << operator and avoid numbering them. The last 4 can be created from 0, 1, <<, and const+.

0
1
<<(b c) //In Java, bitShift is written as b << c. Example: <<(1 1) is 2.
+(b c) //Example: +(<<(1 1) 1) is 3. Example: +(<<(1 <<(1 1)) 1) is 5
*(b c)
varSize+(b b b)
^(b c)
varSize*(b b b)

Error, "+(b c) --> <<(b c)" does not work but "+(3 7) --> 2" does.

The following operators, and more, would have to be added as branches to this tree. The tree is only a list for now:
<<(b c)
factorial(b)
triArayWithDiag(b)
triArayWithoutDiag(b)

These are the best sequence of operators where each is a superset of the last:
0[error]
1[0]
2[1]
+(b c)[2]
*(b c)[2]
varSize+(b b b)[c] //c quantity of b's
^(b c)[2]
varSize*(b b b)[c] //c quantity of b's

2[1] can not be combined with intConstant[1] (instead of being its sibling) because neither is a subset of the other?

Should factorial be added somewhere?
factorial[1](b)
Equal to if[3](b *[2](b factorial[1](b-1)) 1). Hard to define because I may not add the minus or divide size operators until next year.
Equal to *[2](b factorial[1](b-1))
factorial[1](b) //Example if b==3: Equal to *[2](4 *[2](3 2))
factorial3[0]
factorial4[0]

<important>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[error]
	.	1[0]
	.	.	2[1]
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	varSize+[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	varSize*[c](b b b) //c quantity of b's. FROM 0[error] TO HERE IS THE DEFAULT PATH.
	.	.	.	<<[2](b c) //bitShift. Used for optimization.
	.	.	javaObject[1] //Anything
	.	.	.	Func[1]
	.	.	floConstant[1] //Not an array, but is size 1
	.	.	intConstant[1] //Not an array, but is size 1
</important>

<importantIncludingOnlyTheSimplestSizeOperators>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[error]
	.	1[0]
	.	.	2[1]
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	varSize+[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	varSize*[c](b b b) //c quantity of b's. FROM 0[error] TO HERE IS THE DEFAULT PATH.
</importantIncludingOnlyTheSimplestSizeOperators>


Using the things in that tree, define the example node, quoted below:

[QUOTE FROM createExampleNode.13.xml]
<araysOfExampleNode>
	int myInts[1] //size is defined as constant 1
	Func myFuncs[araysInConstantDepthRecursion.length] //size is defined as constant, number of Funcs in this Node.

	int hq[h]        //size is defined in some range. Index always stays at 0 (or 1?).
	int hqReverse[h] //size func: size=(hq hqReverse)
	flo hqFlo[h]   //size func: size=(hq hqReverse)
	Ob hqNode[h] //size func: size=(hq hqReverse)

	Ob child[c]    //size is defined in some range
	flo childWeight[c] //size func: size=(childWeight child)
	////////ABOVE ARRAYS ARE REAL, BELOW ARE VIRTUAL////////

	//Get first hq node 1 time.
	Ob hqCurNode[] //func: pointer(hq hqCurNode)
	flo hqCurValue[]   //func: pointer(hq hqCurValue)

	//Get variable-size child array of that node. Iterate over each child.
	Ob childOfHqCurNode[]    //func: arayInChild(hqCurNode child childOfHqCurNode)
	flo childWeightOfHqCurNode[] //func: arayInChild(hqCurNode childWeight childWeightOfHqCurNode)

	//Find a child in hq. This is 1 thing to do in the existing iteration.
	Ob hqNodeForChildOfHqCurNode[] is virtual view of hqNode[]. //func: logSearchForNode(childOfHqCurNode hqNodeForChildOfHqCurNode) //TODO What if its not found? Should that be an error? Should it give index -1, index 0, null?
	flo hqFloForChildOfHqCurNode[] is virtual view of hqFlo[]. //func: index=(hqNodeForChildOfHqCurNode hqFloForChildOfHqCurNode)

	//TODO use bit array (maybe size 1) to store the boolean value of if hqCurValue is big enough to continue

	? rootIterAndCodeOfExampleNode = ...defined below...
</araysOfExampleNode>

<Func>
	sequence(
		viewAray(hqNode hqNodeForChildOfHqCurNode) //hqNode goes in multiple places so we can have 2 curIndex for it.
		viewAray(hqFlo hqFloForChildOfHqCurNode) //hqFlo goes in multiple places so we can have 2 curIndex for it.
		viewAray(hqNode hqCurNode)
		viewAray(hqFlo hqCurValue)
		pointer(hq hqCurNode) //set curIndex of hqCurNode to the highest in the hq
		pointer(hq hqCurValue) //set curIndex of hqCurNode to the highest in the hq
		arayInChild(hqCurNode child childOfHqCurNode)
		arayInChild(hqCurNode childWeight childWeightOfHqCurNode)
		flo-=(hqCurValue ???totalAmountChange???)
		hqFloChanged(???hq??? ???hqReverse??? hqCurValue) //should this be merged with flo-=(...) above?
		recurse(
			childOfHqCurNode
			sequence(
				logSearchForNode(childOfHqCurNode hqNodeForChildOfHqCurNode)
				index=(hqNodeForChildOfHqCurNode hqFloForChildOfHqCurNode)
				flo+=(hqFloForChildOfHqCurNode ???totalAmountChangeDividedByChildQuantity???)
				hqFloChanged(???hq??? ???hqReverse??? hqFloForChildOfHqCurNode) //should this be merged with flo+=(...) above?
			)
		)
	)
</Func>
[END QUOTE FROM createExampleNode.13.xml]

<importantIncludingOnlyTheSimplestSizeOperators>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[error] //Should this be 0[0] or 0[1] or 0[error]? Do we need a [size] on all of these?
	.	1[0] //Should this be 1[0] or 1[1]? Do we need a [size] on all of these?
	.	.	2[1] //Should this be 2[0] or 2[1]? Do we need a [size] on all of these?
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	varSize+[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	varSize*[c](b b b) //c quantity of b's. FROM 0[error] TO HERE IS THE DEFAULT PATH.
</importantIncludingOnlyTheSimplestSizeOperators>

int = varSize*[32](2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2)

Using the things in that tree, define a more complex bayesian node, that has 3 * 2^childCount weights.

<newSyntax>
	This syntax maybe will only be used in this file, or it may become part of Audivolv.
	Need a new syntax to write these things differently: size of x, current index of x, x as an aray.
	There may be many current indexs of x, each a different virtualAray view of x.
	Also, we may need a syntax for the content of x at the current index of x.

	Do we really need a syntax for the size of x? It could be defined as the value of the operator instead of explicitly.
	Do we really need a syntax for an index in x? Can use value in x without explicitly using the index of that value.

	We need a syntax for defining constant depth recursion, like floAray of childAray of otherChildAray of childAray of childAray.
	In this syntax, we are not defining types (like flo or int or Object) yet, but will do that later.
	Arays are Object and only aray can be recursed.

	Should a new * (with parameters b and c) named themult be defined this way?: *.themult[b c]
	Should a new linear iterator, also called a view, over themult be defined this way?: themult.newvarname[b c]
	Should a new linear iterator, also called a view, over themult be defined this way?: =.newvarname[themult]
	Should a new linear iterator, also called a view, over themult be defined this way?: themult.newvarname

	How can the ints in 2 intArays in a heapQueue be defined as pointing at the opposite intAray?
	intConstant.hqIntAray[]
	hqIntAray.hqReverseIntAray
	<constraint>
		Constraint: hqIntAray.hqReverseIntAray == hqIntAray
		Constraint: hqReverseIntAray.hqIntAray == hqReverseIntAray
		hqIntAray.hqReverseIntAray means the value in hqIntAray at the current index of hqReverseIntAray.
		hqReverseIntAray.hqIntAray means the value in hqReverseIntAray at the current index of hqIntAray.
		If they were Object arrays instead, hqObAray.hqReverseObAray would mean some specific Object in hqObAray???
		This syntax is confusing. Make it less vague.
	</constraint>


	X as an aray           : x
	//Size of x:
	//Index b of x
	//Index c of x
	Content of x at index b: x.b
	Content of x at index c: x.c
</newSyntax>

//bayesNode with 3 * 2^childCount weights, excluding heapQueue, func aray, and default myInts aray
+.bayesNode[
	intConstant.someVar[] //size 1
	intConstant.falseTrue[] //size 2
	intConstant.child[] //size between 1 and 7
	intConstant.threeThings[] //size 3
	*.weightSum[falseTrue child]
	*.threeWeightSum[threeThings weightSum]
	*.weight[threeThings ^.childCombinations[falseTrue child]]
]

*.weight[ threeThings {*.weightSum[falseTrue child] <-- varSize+[1 falseTrue for each child] <-- ^[falseTrue child]} ]

<importantIncludingOnlyTheSimplestSizeOperators>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[error] //Should this be 0[0] or 0[1] or 0[error]? Do we need a [size] on all of these?
	.	1[0] //Should this be 1[0] or 1[1]? Do we need a [size] on all of these?
	.	.	2[1] //Should this be 2[0] or 2[1]? Do we need a [size] on all of these?
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	varSize+[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	varSize*[c](b b b) //c quantity of b's. FROM 0[error] TO HERE IS THE DEFAULT PATH.
</importantIncludingOnlyTheSimplestSizeOperators>

Rename "varSize+" to "+?"?
Rename "varSize*" to "*?"?

Change the things in bayesNode to refer to eachother more:

+.bayesNode[
	intConstant.someVar[] //size 1
	intConstant.falseTrue[] //size 2
	intConstant.child[] //size between 1 and 7
	intConstant.threeThings[] //size 3
	*.weightSum[falseTrue child]
	*.threeWeightSum[threeThings weightSum]
	*.weight[threeThings threeWeightSum.^.childCombinations]
]

To explain how this works, go unnecessarily higher in "Tree (tabs define parent/child), where parent is always a subset of child".

+.bayesNode[
	intConstant.someVar[] //size 1
	intConstant.falseTrue[] //size 2
	intConstant.child[] //size between 1 and 7
	intConstant.threeThings[] //size 3
	zero.aNumberZero.one.aNumberOne.two.aNumberTwo.+.falseTrueAndChild[falseTrue child].*.weightSum //weightSum is falseTrue*child
	aNumberTwo.+.threeThingsAndWeightSum[threeThings weightSum].*.threeWeightSum //threeWeightSum is threeThings*(falseTrue*child)
	aNumberTwo.+.xyz[threeThings threeWeightSum.^.childCombinations].*.weight //weight is threeThings*(threeThings^(falseTrue*child))
]

if.theBayesFunc[
	flo<.someVarIsSmall[someVar 0.05]
	do.listOfThingsToDo[
		weight.
		...
	]
]

Should there be a special syntax for literal array?
Example: int.5.[4 4 10 10 10].*.thisArayIsSize16000
Example: int.2.[int.3 int.5].^.thisArayIs3Power5
Example: [[x y z] int.5].^.thisArayIs3Power5
is abbreviation for: audivolv.int.2.[audivolv.int.3.[x y z] audivolv.int.5].+.^.thisArayIs3Power5

Should string-literals be usable as aray of UTF-8 char?
Example: audivolv.int.2.[audivolv.int.2."ab" audivolv.int.3."cde"].the2Strings.+.*.theSize6StringMult
Iterating over theSize6StringMult while using the2Strings as data,
you get these 6 things: "be", "bd", "bc", "ae", "ad", then "ac", which are each a size-2 aray.
That may make processing strings easy enough that Audivolv could be used for natural-language.

It can be abbreviated ["ab" "cde"].the2Strings.*.theSize6StringMult

Iterating over theSize6StringMult.^ using the2Strings.+ as data,
you get these 8 things: "bbb", "bba", "bab", "baa", "abb", "aba", "aab", "aaa".

How to define the 2 things relevant to iteration?: root object (theSize6StringMult.^) and data object (the2Strings.+).

[audivolv.int.2."ab" audivolv.int.3."cde"].the2Strings.+.*.theSize6StringMult


<importantIncludingOnlyTheSimplestSizeOperators>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[error] //Should this be 0[0] or 0[1] or 0[error]? Do we need a [size] on all of these?
	.	1[0] //Should this be 1[0] or 1[1]? Do we need a [size] on all of these?
	.	.	2[1] //Should this be 2[0] or 2[1]? Do we need a [size] on all of these?
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	varSize+[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	varSize*[c](b b b) //c quantity of b's. FROM 0[error] TO HERE IS THE DEFAULT PATH.
</importantIncludingOnlyTheSimplestSizeOperators>

<variationOf_importantIncludingOnlyTheSimplestSizeOperators>
	Tree (tabs define parent/child), where parent is always a subset of child:
	0[0]
	.	1[0]
	.	.	2[0]
	.	.	.	+[2](b c)
	.	.	.	.	*[2](b c)
	.	.	.	.	.	+?[c](b b b) //c quantity of b's
	.	.	.	.	.	.	^[2](b c)
	.	.	.	.	.	.	.	*?[c](b b b) //c quantity of b's. FROM 0[0] TO HERE IS THE DEFAULT PATH.
</variationOf_importantIncludingOnlyTheSimplestSizeOperators>

How to do the bayesian algorithm to combine 2 arays of data, sizes b*c and b^c, in iteration size c*(b^c)?

+.bayesNode[
	intConstant.someVar[] //size 1
	intConstant.falseTrue[] //size 2
	intConstant.child[] //size between 1 and 7
	intConstant.threeThings[] //size 3
	//weightSum is falseTrue*child
	[falseTrue child].*.weightSum
	//threeWeightSums is threeThings*(falseTrue*child)
	[threeThings weightSum].*.threeWeightSums
	//weight is (threeThings^weightSum)*weightSum
	[threeWeightSums.^.childCombinations weightSum].*.weight
	//Can rewrite the above line as: ?????
	[threeWeightSums.^.childCombinations threeWeightSums].^*.weight ????? //TODO Iteration size is reduced by combining ^ and *
	//Another rewrite of that line: ?????
	threeWeightSums.^.weight.^*.theIter //[x y].^.^* (or abbreviated [x y].^.^*) has iteration size (x^y)*y
	//This is the simplest possible rewrite:
	threeWeightSums.^*
]

What if I want iteration size (x^y)*y but I want the y to iterate in an unusual order, like heapQueue order?
[x y y.intFromHeapQueue].^* ???

[x y].^.weight.varSize*.varSizeViewOfWeight.intFromHeapQueue ????? //How does intFromHeapQueue change each iteration?


Would this work better?
[x y].^.weight.varSize*.varSizeViewOfWeight.func.newFuncName[pointer[theHeapQueue ???] ???].??????


The most common case appears to already be solved.
+[2](b c) <-- *[2](b c) <-- varSize+[c](b b b) <-- ^[2](b c)
If *[2](b c) is data, and iteration size includes ^[2](b c), then ??? multiplying by c is forced or staying as an array size c is forced.
If *[2](b c) is size-1 data per iteration, then multiplying by c is forced.
If *[2](b c) is size c instead of size 1, then it is written wrong and is instead varSize+[c](b b b).
Doing "*[2](b c) <-- varSize+[c](b b b)" requires an extra c index.




<defaultTransformsDetails>

	Need to specify the difference between integer 9 and the contents of an aray size 9.

	For all transformations in the default linkedlist/tree, define the possible ways to transform or use:

	*?[c](b b b) --> ^[2](b c)
		These things contain equal data but view it differently. Why should one be a subset of the other?

	^[2](b c) --> +?[c](b b b)
		One index iterating over ^[2](b c) gives c quantity of index in +?[c](b b b).
		2 indexs iterating over ^[2](b c) requires those 2 indexs be c and b^c, which is +?[c](b b b) * c, and

	+?[c](b b b) --> *[2](b c)
		These things contain equal data but view it differently. Why should one be a subset of the other?

	*[2](b c) --> +[2](b c)


	+[2](b c) --> 2[0]

	2[0] --> 1[0]

	1[0] --> 0[0]

	0[0] --> audivolv

	audivolv //is the root of everything
</defaultTransformsDetails>



The existing design of default transforms (those 8 things in a linkedlist/tree) is ambiguous how to combine * and ^ the normal bayesian way. Change them to each specify exactly 1 way to use them, and create more if necessary so all ways to use them are available.

All operators except the first few should be defined in terms of simpler operators, starting with the idea of integer and aray and maybe dimension. There will be logical definitions (Example: integer or aray) and arbitrary definitions (Example: flo or Func).

Should 3+4+2 be definable this way?: 3.+.threePlus4[4].+.threePlus4Plus2[2]
The current way to define it is: +.threePlus4Plus2[3 4 2]

aray[...variable size...]

When I say "index for b", it means it is used with something size b. There is no need to specify which of b and c its for if you give an index for b to use with +[b c].

Should every aray of indexs (like an int aray) specify which aray the indexs are for?


"c quantity of indexs for b"
	WayToUse: index for c --> index for b

^[b c] //If c is 4: *[b *[b *[b *[b 1]]]]
	WayToUse: index for ^[b c] --> c quantity of indexs for b
	WayToUse: c quantity of indexs for b --> index for ^[b c]
	WayToUse: Sequentially: ^[b c] quantity of indexs for ^[b c].
	WayToUse:
	WayToUse:

"c quantity of index for *[b c]"
	WayToUse: index for c --> index for *[b c]
	WayToUse: Sequentially: c quantity of index for *[b c]
	WayToUse: Sequentially: c quantity of index for c

*[b c] //If c is 4: +[b +[b +[b +[b 0]]]]
	WayToUse: index for *[b c] --> index for b and index for c
	WayToUse: index for b --> c quantity of index for *[b c]
	//Do we need this one? WayToUse: index for c --> b quantity of index for *[b c]
	//can be derived from WayToUse above: WayToUse: index for b and index for c --> index for *[b c]
	Sequentially: *[b c] quantity of indexs for *[b c].

+[b c] //[b c] is size 2. +[b +[c 0]]
	WayToUse: index for +[b c] --> index for 2 and [index for b or index for c]
	WayToUse: index for 2 and [index for b or index for c] --> index for +[b c]
	WayToUse:
	WayToUse:
	WayToUse:
	Sequentially: +[b c] quantity of indexs for +[b c].

Defining behavior only, not data structures, should each operator be arays containing arays which each need indexs?
Example: oneDimensionalAray[c d b] has 1 index which ranges 0..2, because its size is 3.
Example: 3 has 1 index which ranges 0..2, because its size is 3. Its size is 3 because all integers are the size of their value.
Example: 0 has no indexs because no integer is at least 0 and at most 0-1.
Example: +[2 2 2] has 2 indexs: 0..2 and 0..1, because its a 2d array size 3 and inner aray size 2: [[a b] [c d] [e f]].
Example: +[9 9] has 2 indexs: 0..1 and 0..8, because its an aray of 2*9 things.
Example: *[9 9 9 9] has 4 indexs, each 0..8, because this is the same as a 4 dimensional + aray.
Example: *[9 9] has 2 indexs.
Example: *[3 5] has 2 indexs, the same quantity of indexs as +[5 5 5] has. For both, the first index is 0..2 and the second is 0..4.
Example: *[3 5 4] has 3 indexs, the same quantity of indexs as +[*[5 4] *[5 4] *[5 4]] has,
	and the same quantity of indexs as +[+[4 [0 0 0 0] 4 4 4] *[5 4] *[5 4]] has.
Example: ^[9 4] has 4 indexs, each ranging 0..8, the same ranges and indexs as *[9 9 9 9] has.


A more consistent definition of integers, plus, multiply, and power in a set-theory way:

0 has no dimensions. It is the empty set, the plus of 0 things: +[].
p is any positive integer. It is the + operator with p quantity of parameters that are all 0. 3 is +[0 0 0].
+[b c d] has an integer size 3, and for each of those has a size b or c or d. If b and c and d are 4 dimensionl, +[b c d] is 5 dimensional and the outer dimension is size 3.
*[b c d] has integer size b.

That has too many words. Start that paragraph over.
+[] is 0, an empty list.
+[0 0 0] is 3, a list of 3 empty lists.
+[0] is 1, a list containing only 1 thing: an empty list.
+[+[0] +[0] +[0]] is a list of 3 things, and each of those things is 1, so this sums to 3 for the same reason +[+[a b] c] sums to +[a b c], but that loses the grouping information.
*[3 3 3 3 3] is the same as +[*[3 3 3] +[*[3 3] *[3 3] *[3 3]] *[3 3 3] *[3 3 3]]
^[3 5] is the same as *[3 3 3 3 3].

+[] is 0 and has 0 dimensions.
+[0 0 0] is 3 and has 1 dimension.
+[+[0] +[0] +[0]] is +[1 1 1] and has 2 dimensions.
*[7 6 5 4 3 2 1] has 7 dimensions.
*[7 6 5 4 3 2] has 6 dimensions.
^[3 5] and *[3 3 3 3 3] and has 5 dimensions.

How can +[0 0 0] and +[1 1 1] both eval to 3? Adding 0 should not change it, but it does make the equation longer.
+[0 0 0] is +[+[] +[] +[]], which reduces to +[] for the same reason +[+[a b] c] reduces to +[a b c].

Should +[1] equal 1? If yes, then +[1] equals +[+[+[1]]]

Rewrite that paragraph with the new info about 1.

+[] is 0, an empty list.
+[1] is 1.
+[1 1 1] is 3.
*[3 3 3 3 3] is the same as +[*[3 3 3] +[*[3 3] *[3 3] *[3 3]] *[3 3 3] *[3 3 3]]
^[3 5] is the same as *[3 3 3 3 3].

Most things can be viewed as having infinite dimensions and most of those dimensions are size-1 with the only possible value being 0.
The only things that have a finite number of dimensions contain +[] which equals 0 and has no possible value.

Can flo (floating point number) be a number in this system?
How can 3.5 be defined?
Should we use a base-negative-2 positional number system to describe the dimensions, which would allow fractions? That probably would not work because iterating over dimensions has to start at the first dimension and go up.
Is it easier to define e (2.71...)?

Should +[3.5] be 1 because [] does not understand flo?
Should +[someFunc] be 1 because [] does not understand someFunc?
Should +[someFunc] reduce to someFunc for the same reason +[+[a b] c] reduces to +[a b c]?
"be" and "reduce to" are confusing.

A more practical example, arays in a node:

+.theNode[
	+.falseTrue[false true]
	+.threeThings[b c d]
	+.child[...]
	^.weight[2 child]
	*.weightSum[falseTrue child]
	*.threeWeightSum[threeThings weightSum]
	*.weight[threeThings ^.childCombinations[falseTrue child]]
]

Should every aray be viewed through an assumed int aray its same size and containing the int x at index x?
Reasons: to be compatible with the 2 intarays in a heapQueue which point other places, and to be compatible with iterating and variable quantity of indexs from single operators.


<indexsAndOperators>

	We only want to use ^ with 2 parameters, so that can be calculated as variable size *.
	+ only uses 1 index at a time, so its calculations do not have variable-size indexs.
	All size calculations can be done with constantInt, +, and *.
	The main problem to solve is how to use x quantity of indexs (from a * size x) with an index ranging 0 to x-1.


	***TODO REWRITE THIS***
	"c quantity of indexs for b"
		WayToUse: index for c --> index for b

	^[b c] //If c is 4: *[b *[b *[b *[b 1]]]]
		WayToUse: index for ^[b c] --> c quantity of indexs for b
		WayToUse: c quantity of indexs for b --> index for ^[b c]
		WayToUse: index for c and index for b --> b^(c-1) quantity of indexs for ^[b c] //can this be done efficiently?
		WayToUse: Sequentially: ^[b c] quantity of indexs for ^[b c].
		WayToUse:
		WayToUse:

	"c quantity of index for *[b c]"
		WayToUse: index for c --> index for *[b c]
		WayToUse: Sequentially: c quantity of index for *[b c]
		WayToUse: Sequentially: c quantity of index for c

	*[b c d]
		WayToUse: index for *[b c d] --> index for b and index for c and index for d
			//same as "index for ^[b c] --> c quantity of indexs for b" if vars are renamed.
		WayToUse: index for b --> *[c d] quantity of index for *[b c d]
		WayToUse: index for c --> *[b d] quantity of index for *[b c d]
		WayToUse: index for d --> *[b c] quantity of index for *[b c d]
		WayToUse: index for *[b d] --> c quantity of index for *[b c d]
		Sequentially: +[] --> *[b c d] quantity of indexs for *[b c d].

	*[b c] //If c is 4: +[b +[b +[b +[b 0]]]]
		WayToUse: index for *[b c] --> index for b and index for c
		WayToUse: index for b --> c quantity of index for *[b c]
		//Do we need this one? WayToUse: index for c --> b quantity of index for *[b c]
		//can be derived from WayToUse above: WayToUse: index for b and index for c --> index for *[b c]
		Sequentially: *[b c] quantity of indexs for *[b c].

	+[b c] //[b c] is size 2. +[b +[c 0]]
		WayToUse: index for +[b c] --> index for 2 and [index for b or index for c]
		WayToUse: index for 2 and [index for b or index for c] --> index for +[b c]
		WayToUse:
		WayToUse:
		WayToUse:
		Sequentially: +[b c] quantity of indexs for +[b c].
	***TODO REWRITE THIS***
</indexsAndOperators>


ob theNode = +[
	ob falseTrue = +[false true]
	ob threeThings = +[b c d]
	ob child = +[...]
	threeTimesChild = *[threeThings child]
	flo smalAray = *[falseTrue threeTimesChild]
	flo bigAray = ^[falseTrue threeTimesChild]
	//iterSmalAndBigArays = *[smalAray.threeTimesChild bigAray] this doesnt make sense. How does smalAray get a value of falseTrue?
	//iterSmalAndBigArays = *[threeTimesChild bigAray]
	//size (falseTrue*threeTimesChild)*(falseTrue^(threeTimesChild-1))
	iterSmalAndBigArays = *[smalAray /[bigAray smalAray.threeTimesChild]]
]

iterSmalAndBigArays = *[smalAray /[bigAray smalAray.threeTimesChild]]
does not make sense because the whole bigAray should be iterated over and during that get a falseTrue index out of bigAray when force a threeTimesChild index into bigAray.

There should be a syntax for forcing index(s) into things and getting extra index(s) out of them.
Example: Forcing an index for c into b^c creates an index for b.
Only certain index(s) can be forced into each thing. An index for b can not be forced into b^c because there may be no b with that index or there may be many, but there are always c quantity of arbitrary b indexs.
mul = *[b c]
mul.pointers returns [b c] which is 2 indexs
pow = ^[b c]
pow.pointers returns [b b b b b ...c quantity of b...] which is c indexs

/[pow.pointers mul.pointers.c] returns an index for b

Iterate over mul with these pointers: [/[pow.pointers mul.pointers.c] mul.pointers.c]
mul.pointers = [/[pow.pointers mul.pointers.c] mul.pointers.c]
mul.pointers.b = /[pow.pointers mul.pointers.c]

pow.iter[ //iteration size b^c
	pow.pointers.iter[ //iteration size c. Var "c" increases from 0 to c-1. Var "b" is the pointer at index c.
		mul.pointers.b = pow.pointers.b
		mul.pointers.c = pow.pointers.c //This is too much to write. There should be a more direct way to connect ^ and *.
	]
]


I like this syntax because it is short and puts c then b into the namespace which specifies which index in mul to use.
ob bayesNode = +[
	void b = 2 //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode c = +[0..6] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	flo mul = *[b c] //a floating point array, size b multiply c
	flo pow = ^[b c] //a floating point array, size b power c
	ob theFuncs = +[ //list of functions that can be run in a bayesNode
		setFlosInMul = +[ //a function named setFlosInMul
			mul.loop.flo=[mul 0.] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]
pow is a flo aray size b^c.
pow.loop is a command, and during it, pow.loop equals pow with 1 extra thing available: the c aray which was defined somewhere else in the bayesNode.
pow.loop.c is that c aray.
pow.loop.c.loop is a command thats run inside the pow.loop command, and during it, pow.loop.c.loop equals pow.loop.c with 1 extra thing available: the b aray which was defined somewhere else in the bayesNode.
pow.loop.c.loop.b is that b aray.
pow.loop.c.loop.b.flo+= is a command run inside those other 2 commands recursively, and its parameters are [mul pow].
Because of recursion, b and c are defined in pow. Because mul is used here, it uses the b and c in this local namespace instead of its own.

TODO add something to this syntax that would allow pow's c and mul's c
to be used independently: pow.loop.c.loop.b.flo+=[pow "use mul.loop here" mul]

This is also allowed: mul.b.loop is the c aray.

pow.b and pow.c are not allowed because they only exist when looping in that sequence. That limited existance makes evolved code more likely to find that combination. It exists more often when it would make sense to use it.

Rewrite that syntax (where the bayesNode is written) to not use the = operator or void/flo/ob as a different syntax rule than normal dot syntax.

How to write int 3 and flo 3 and floAray size 3 differently?

obAray.+.bayesNode[
	voidAray.b.2 //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode.range.c[0 6] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	floAray.*.mul[b c] //a floating point array, size b multiply c
	floAray.^.pow[b c] //a floating point array, size b power c
	obAray.+.theFuncs[ //list of functions that can be run in a bayesNode
		+.setFlosInMul[ //a function named setFlosInMul
			mul.loop.flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]

The order of floAray.^.[b c].pow is confusing when applied to obAray.+.bayesNode[...bayesNode...] because bayesNode's [] refers to bayesNode.

Should {2 5} mean integer between 2 and 5 inclusive?
Should {2} mean integer 2?
Should (2 3.1) mean flo between 2 and 2.3 inclusive?
Should (2) mean flo 2.0?

Why should intRange and ^ have different syntaxs {} and []?
Instead, literally specifying the contents of intRange or ^ should be the exception.

I maybe dont need extra syntax for flo range.
I dont need extra syntax for int range because "range" can be an array size operator the same way "^" and "*" are.

These things are defined by default (and I may rename them, but they can not be renamed at runtime):
audivolv.void
audivolv.int
audivolv.0
audivolv.1
audivolv.2
audivolv.3 //and other int constants
audivolv.flo
audivolv.ob //ob can be anything
audivolv.func
audivolv.range
audivolv.+
audivolv.*
audivolv.^
audivolv.loop
audivolv.aray //aray of anything
audivolv.[] //literal aray. Specify the contents of the aray by putting them between [ and ]


This is the definition of a simple and incomplete type of bayesNode:

ob.aray.+.bayesNode[
	void.aray.2.b //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode.aray.range.[0 6].c //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	flo.aray.*.[b c].mul //a floating point array, size b multiply c
	flo.aray.^.[b c].pow //a floating point array, size b power c
	ob.aray.+.theFuncs[ //list of functions that can be run in a bayesNode
		+.setFlosInMul[ //a function named setFlosInMul
			mul.loop.flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]

Make it more consistent. Should each literal array [] have a name? Or should that name be separated by a dot, like thename.[stuff]?

Things preceding a dot may only allow certain things after the dot.
Example: flo.aray.size^ may only allow a literal aray size 2, like this: flo.aray.size^.theFloAray[1 4]
The definition of what can come after flo.aray.size^ may be written this way: [int int], or it may be written this way: [araySize araySize].
I am not sure how to consistently write that.

Should this syntax be like Lisp, where everything is in a list (aray in this case) even if its not written?
Example: flo.aray.size*.mul[b c] could be the same as [flo].[aray].[size*].mul[b c]
or should it instead be the same as flo[].aray[].size*[].mul[b c]?
b and c are defined before that, so how should they be written?
Neither of these makes sense: mul[b[] c[]] or mul[[b] [c]]
Should it be like Lisp where the name of an aray goes in that aray, and a cdr command gets it without that?
[flo].[aray].[size*].[mul b c]
What does the dot syntax mean if its like Lisp?
Multiple things in an array would be Lisp's cdr (second). Would dot mean Lisp's car (first)?
[audivolv.flo].[audivolv.aray].[audivolv.size*].[?...mul ?...b ?...c]
If it is like Lisp that way, [a b c].[d e f] would be the same as [a b].[c d].[e f], and that is a problem.
audivolv.flo.aray.size*.mul[b c]
Should aray be combined with each size operator?
Example: audivolv.flo.araySize*.mul[b c]
Example: audivolv.flo.araySizeRange.c[0 6]


ob.araySize+.bayesNode[
	void.araySize=.b[2] //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode.araySizeRange.c[0 6] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	flo.araySize*.mul[b c] //a floating point array, size b multiply c
	flo.araySize^.pow[b c] //a floating point array, size b power c
	func.arayLit.theFuncs[ //list of functions that can be run in a bayesNode
		araySize+.setFlosInMul[ //a function named setFlosInMul
			...ERROR. mul IS ONLY THE SIZE DEFINITION OF AN ARAY, SO HOW CAN IT LOOP?...
			mul.loop.flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]


If some things after dot are actions instead of objects/arays/etc, then those things can not be used as variables.
Example: Either of 2 "loop" in: pow.loop.c.loop.b.flo+=[mul pow]

Should I allow a string-literal to be used at any time to refer to the last thing written in code that contains that substring?
Example: The "ow" means the "pow" in: pow.loop.c.loop.b.flo+=[mul "ow"]
That would let you refer to "pow.loop" or "c.loop".
That may be slow. I will only use it if it costs no speed at runtime. Independent of that, its probably too vague.

ob.arayLit.bayesNode[
	void.araySize=.b[2] //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode.araySizeRange.c[0 6] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	flo.araySize*.mul[b c] //a floating point array, size b multiply c
	flo.araySize^.pow[b c] //a floating point array, size b power c
	func.arayLit.theFuncs[ //list of functions that can be run in a bayesNode
		araySize+.setFlosInMul[ //a function named setFlosInMul
			...ERROR. mul IS ONLY THE SIZE DEFINITION OF AN ARAY, SO HOW CAN IT LOOP?...
			mul.loop.flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]

The difference between aray and aray literal is confusing.

ob.araySize+#bayesNode[
	void.araySize=#b[2] //This is void because a number is not an aray but it can be viewed as the size of an aray.
	bayesNode.araySizeRange#c[0 6] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	flo.araySize*#mul[b c] //a floating point array, size b multiply c
	flo.araySize^#pow[b c] //a floating point array, size b power c
	func.arayLit#theFuncs[ //list of functions that can be run in a bayesNode
		arayLit#setFlosInMul[ //a function named setFlosInMul
			...ERROR. mul IS ONLY THE SIZE DEFINITION OF AN ARAY, SO HOW CAN IT LOOP?...
			mul.loop.flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]

It is not looking consistent. Forget Lisp. Create the simplest syntax for Audivolv possible. Most data is arays in arays recursively. Most arays are flo[] or ob[]. Most function calls will be on Java objects that were compiled as optimizations of Audivolv code.

Should the dot syntax be replaced by []? Dots could be used as abbreviations of something involving those array literals. Try it here to see how it would look.

bayesNode[
	defAray#b[void araySize=[2]] //This is void because a number is not an aray but it can be viewed as the size of an aray.
	defAray#c[bayesNode araySizeRange[0 6]] //min size 0. max size 6. Contains bayesNode's, a recursive definition.
	defAray#mul[flo araySize*[b c]] //a floating point array, size b multiply c
	defAray#pow[flo araySize^[b c]] //a floating point array, size b power c
	theFuncs[ //list of functions that can be run in a bayesNode
		setFlosInMul[ //a function named setFlosInMul
			ERROR HOW TO DEFINE THIS WITHOUT DOT?: loop[mul].flo=[mul 0] //set all flos in mul to 0
			pow.loop.c.loop.b.flo+=[mul pow] //add flos in pow to flos in mul, mapping many indexs in pow to mul.
		].loop //loop to run all commands in the function
	]
]

Without dot syntax, it looks like something I wrote months ago and did not like. I want the syntax to have dots, but what should they do?


Consider this linkedlist/tree. I thought it was going to be very useful in defining audivolv syntax and logic, but I couldnt make it fit completely:

varSize*(b b b) --> ^(b c) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> 0









</syntaxSimilarToASubsetOfRuby>
